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1.  INTRODUCTION 

This  Quarterly  Technical  Report  No.  7  describes  several 
aspects  of  our  technical  progress  on  the  ARPA  Computer  Network 
during  the  third  quarter  of  1970. 

•  During  this  period,  we  installed  IMPs  No.  10  and  No.  11 
at  Lincoln  Laboratories  and  Stanford  University,  commenced 
experimental  testing  with  230.4  kilobit/sec  circuits  in  the 
test  cell  at  BBN,  and  completed  retrofits  of  new  control  panels 
and  auto  restart  circuitry. 

•  We  developed  a  new  version  of  the  operational  IMP  pro¬ 
gram  (IMPSYS  24)  for  release  in  November  1970.  The  organization 
of  the  IMF  program  has  been  substantially  changed  from  the  pre¬ 
vious  operational  program  to  allow  a  large  number  of  modifica¬ 
tions  to  be  efficiently  incorporated.  This  activity  is  described 
in  Section  2. 

•  A  primary  development  effort  during  this  quarter  has  been 
directed  toward  the  preliminary  design  of  the  terminal  IMP. 

Initial  logic  design  has  been  completed  fo  a  multi-line  con¬ 
troller  that  will  handle  up  to  64  asynchronous  or  synchronous 
terminal  devices,  and  all  standard  codes  and  speeds.  In  ad¬ 
dition,  we  have  produced  preliminary  coding  of  the  inner  loop 

of  the  terminal  IMP  program.  This  effort  is  described  in  Section  3. 
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•  The  Network  Control  Center  has  now  been  In  operation  for 
over  three  months.  This  effort  has  progressed  particularly 
smoothly.  A  mini-Host  was  constructed  in  the  prototype  IMP  for 
use  by  Network  Control  Center  personnel  in  obtaining  hourly 
summaries  of  network  performance.  A  sample  of  this  summary 
information  is  presented  in  Section  4. 

•  We  have  continued  to  participate  in  discussions  of  Host 
protocol.  Several  modifications  have  been  made  to  the  IMP  pro¬ 
gram  to  conform  with  the  Host  protocol.  In  addition,  we  formu¬ 
lated  an  alternate  Host  protocol  scheme.  This  activity  is 
described  in  Section  5. 
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2.  IMP  PROGRAM  DEVELOPMENT 

During  this  quarter,  the  operational  IMP  program  was  ex¬ 
tensively  revised.  Revision  was  necessary  to  the  efficient 
incorporation  of  many  new  system  features  and  to  modifications 
in  the  new  version  of  the  IMP  Program  (IMPSYS  24),  scheduled 
for  release  in  November. 

New  system  features  include  a  single  line  test  message 
that  each  IMP  transmits  to  its  neighbors  at  half-second  inter¬ 
vals.  All  routing,  HELLO,  and  I  HEARD  YOU  information  is  com¬ 
bined  and  transmitted  in  this  single  message.  Previously, 
these  three  line  test  messages  were  transmitted  separately. 

The  quality  of  a  given  line  is  now  measured  by  the  number  of 
line  test  messages  which  fail  to  get  through  on  that  line  in  a 
time  internal  of  approximately  one  minute. 

A  remote  crosspatching  feature  was  incorporated  to  allow  a 
selected  interface  or  modem  to  be  looped  under  control  of  the 
operational  IMP  program.  This  capability  enables  the  Network 
Control  Center  to  locate  accurately  the  source  of  most  field 
problems.  IMP  personnel  can  now  isolate  a  faulty  communication 
line,  a  faulty  modem,  and  most  hardware  interface  problems 
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directly  from  the  Network  Control  Center.  However,  the  on-site 
assistance  of  Honeywell  or  telephone  company  personnel  is  still 
required  for  subsequent  diagnosis  and  repair. 

The  long-term  timeout  period  was  reduced  from  15  minutes 
to  one  minute.  This  reduction  involved  careful  attention  to 
timing  in  each  of  the  major  system  routines  to  insure  that  the 
sequence  of  time-out  mechanisms  involving  one  or  more  IMPs 
would  be  executed  in  the  proper  order. 

Approximately  a  hundred  minor  revisions  have  been  made  to 
the  IMP  program.  For  example:  1)  partially  reassembled  mes¬ 
sages  are  now  discarded  when  their  source  goes  dead;  2)  the  Host 
can  no  longer  use  all  the  IMP'S  buffers  by  causing  error  mes¬ 
sages  to  be  generated  but  not  accepting  them;  3)  an  IMP  may  be 
induced  to  reload  from  a  specific  line  instead  of  a  random  line; 
4)  the  IMP  number  is  not  changed  when  an  IMP  is  reloaded  with 
its  memory  protect  switch  in  che  off  position;  5)  the  Host 
routines  may  be  put  in  a  hardware  test  mode  by  the  control 
center  to  facilitate  Host  debugging;  6)  all  phone  lines  are 
initialized  to  be  down  rather  than  up. 
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3.  TERMINAL  IMP 

We  have  begun  to  work  on  the  design  of  a  terminal  IMP  that 
will  serve  the  dual  function  of  an  IMP  and  a  terminal  device 
handler.  It  will  provide  a  capability  for  direct  connection 
of  terminals  into  the  net.  Specifically,  the  terminals  need 
not  be  connected  to  a  Host  computer j  but,  rather,  they  may 
access  any  remote  Host  computer  via  the  terminal  IMP  and  the 
network. 

A  brief  description  of  our  initial  design  for  the  terminal 
IMP  and  its  device  handling  capabilities,  as  presently  envis¬ 
ioned,  is  given  below.  Built  into  the  terminal  IMP  will  be  a 
multi-line  controller  capable  of  handling  up  to  64  terminal 
devices.  The  controller  provides  all  of  the  logic  for  assembly 
and  disassembly  of  characters  and  for  transferring  characters 
into  and  out  of  the  IMP'S  memory.  Both  synchronous  and  asyn¬ 
chronous  lines  can  be  handled,  the  practical  distinction  being 
whether  or  not  the  controller  must  provide  the  clocking  signal. 
All  input  characters  must  be  of  "asynchronous  format"  in  that 
both  start  and  stop  bits  are  required  by  the  terminal  IMP.  Out¬ 
put  characters  will  also  be  provided  in  "asynchronous  format" 
to  each  terminal  on  either  synchronous  or  asynchronous  con¬ 
nections.  Character  sizes  of  from  five  to  eight  bits  can  be 
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handled.  The  program  will  be  able  to  set  both  the  character 
size  and  speed  for  each  device,  thus  enabling  the  program  to 
determine  the  type  of  terminal  connection  and  permitting  a 
number  of  options,  such  as  a  dial-up  capability,  to  be  provided. 

A  terminal  device  may  be  operated  on  input  or  output  at 
speeds  up  to  and  including  19.2  kilobits/sec.  However,  no  more 
than  10  devices  may  have  speeds  exceeding  2400  bits/second; 
the  remaining  devices  must  all  be  operated  at  speeds  of  2400 
bits/second  or  less.  The  overall  bandwidth  of  the  terminal  IMP 
for  combined  input  and  output  is  limited  by  the  program’s  capa¬ 
bility  to  process  characters.  Present  estimates  are  that  the 
terminal  handling  bandwidth  will  be  about  100  kilobits/second. 

The  interface  to  the  terminals  will  conform  to  the  RS232 
standard.  A  terminal  device  may  be  directly  connected  to  the 
multi-line  controller  or  a  device  may  be  remotely  connected  yia 
a  modem.  Several  standard  modem  types  will  be  available  on 
cards  that  can  be  housed  in  the  terminal  IMP  enclosure. 

We  have  begun  preliminary  work  on  the  program  design  for 
the  terminal  IMP.  Our  initial  estimates,  based  on  the  Honey¬ 
well  H-316,  indicate  that  the  inner  loops  of  both  the  input 
and  output  sections  require  about  50  cycles  to  process  a 
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character.  The  central  task  on  output  is  to  handle  the  trans¬ 
fer  of  packed  characters  from  a  single  buffer  one  at  a  time 
out  a  multiplexed  DMC  channel.  The  central  task  on  input  is 
to  pack  input  characters  and  to  monitor  the  input  for  mode 
changes.  The  programs  must  also  provide  echoing,  do  character 
conversion  if  needed,  and  must  process  user-specified  infor¬ 
mation  such  as  the  message  destination. 
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4.  NETWORK  CONTROL  CENTER 

During  the  last  quarter,  the  Network  Control  Center  (NCC) 
maintained  the  ARPA  Network,  scheduled  time  as  appropriate  for 
network  maintenance  and  testing,  and  coordinated  activities 
among  Hcneywell,  the  telephone  company,  and  the  sites. 

A  standard  procedure  was  developed  for  site  personnel  to 
report  trouble  or  repairs  directly  to  the  control  center.  In 
most  instances,  requests  for  use  of  the  IMP  to  perform  main¬ 
tenance  or  testing  have  been  easily  coordinated  through  the 
control  center.  At  any  given  time,  the  NCC  has  fairly  complete 
knowledge  of  the  current  and  expected  state  of  the  network,  ar.d 
as  such  is  usually  able  to  deal  straightforwardly  with  most 
problems  that  arise. 

Status  information  on  the  lines  and  IMPs  in  the  net  is 
printed  on  the  IMP  teletype  at  BBN  as  received  from  each  IMP 
in  the  net.  The  NCC  has  been  using  this  information  as  a 
standard  reference  for  monitoring  network  status. 

The  Network  Control  Center  has  also  implemented  a  n^ogram 
to  provide  hourly  summaries  of  network  performance.  This  pro¬ 
gram  has  led  to  a  simplification  in  the  procedures  for  monitor¬ 
ing  the  net,  has  improved  upon  the  capabilities  for  detecting 
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status  changes,  and  has  provided  a  more  convenient  means  of 
recording  information.  We  plan  to  improve  the  capabilities  of 
this  program  during  the  next  quarter. 


A  sample  of  the  summary  output  is  illustrated  below: 
DAY  24 


IMP  STATUS 


TIME  IMP  SITES 

01  02  03  04  05  06  07  08  09  10  11  12 
1200  1  1  1  1  1  1  1  1  1 

LINE  STATES5—""  ——" 


TIME  NETWORK  LINES 

01  02  03  04  05  06  07  08  09  10  11  12  13  14  15 


1200  111111111111111 


LINE 

TOTALS  “(+/-) 

01 

0000/0000 

02 

0000/0000 

03 

0001/0000 

04 

0000/0000 

05 

0000/0000 

06 

0000/0000 

07 

0000/0000 

08 

0007/0000 

09 

0000/0006 

10 

0033/0000 

11 

0006/ 0000 

12 

0000/0000 

13 

0000/0000 

14 

0000/0000 

15 

0000/0000 
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A  mini-Host  system  was  implerented  in  the  prototype  IMP  in 
which  this  program  and  several  other  useful  programs  are  run. 

The  prototype  IMP  is  currently  connected  to  BBN's  regular  IMP. 
The  operational  IMP  program  at  BBN  has  been  temporarily  patched 
so  that  all  messages  to  BBN's  teletype  are  copied  and  passed  to 
the  prototype,  which  in  turn  examines  each  received  message  and 
processes  only  the  trouble  reports. 

Every  hour  on  the  hou’  ,  a  summary  report  is  printed  show¬ 
ing:  1)  the  status  of  each  IMP  in  the  net  at  the  beginning  of 
the  hour  and  each  subsequent  change  in  status;  2)  similar 
status  information  for  all  lines  in  the  net;  and  3)  a  cumulative 
sum  of  line  errors  for  each  line  during  the  hour. 

In  the  current  version  of  the  program,  an  IMP  is  said  to 
be  up  only  if  a  status  report  has  been  received  from  the  IMP 
within  the  last  20  minutes.  A  line  is  said  to  be  up  if  the  IMPs 
at  both  ends  of  the  line  report  it  to  be  up. 
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5.  HOST  PROTOCOL 

Two  new  control  message  types,  cease  sent  and  retract  cease, 
were  added  to  the  IMP/Host  Protocol  to  conform  with  the  Host-to- 
Host  Protocol.  The  cease  sent  is  presented  to  the  Host  whenever 
a  cease  on  link  RFNM  is  constructed.  The  retract  cease  message 
negates  the  effect  of  a  cease  message  if  it  can. 

To  assist  the  Hosts  in  their  debugging  efforts,  we  have 
modified  the  IMP  program  to  discard  any  Host  messages  sent  on  a 
blocked  link.  A  blocked  link  error  message  is  returned  to  the 
Host.  Previously,  the  message  was  not  discarded,  and  the  Host 
line  was  hung  for  15  minutes  in  this  situation.  One  consequence 
of  this  change  is  that  messages  sent  on  blocked  links  from  the 
real  Host  will  be  discarded  to  unblock  the  Host  interface;  mes¬ 
sages  sent  on  blocked  links  from  a  Fake  Host  will  hang  the  Fake 
Host  until  the  link  is  unblocked. 

In  Network  Working  Group  67  a  change  to  the  IMP  program 
was  proposed  that  would  have  resulted  in  the  leader  of  a  message 
being  sent  as  a  separate  message  before  the  text  in  all  communi¬ 
cation  between  the  Host  and  its  IMP.  We  believe  that  this  change 
could  have  simplified  the  Host  message  handling  procedures. 
Although  this  proposed  change  met  with  general  approval,  it 


1 1 


Report  No.  2059 


Bolt  Beranek  and  Newman  Inc. 


would  have  Introduced  a  negative  transient  in  some  Host  efforts 
to  achieve  timely  use  of  the  net.  We  are  therefore  no  longer 
considering  this  change  at  this  time. 

A  Host  protocol  document  entitled  "Interprocess  Communica¬ 
tion  in  a  Resource  Sharing  Network"  was  generated  by  David  Walden 
in  an  effort  to  provide  some  fresh  insights  into  this  area.  The 
scheme  described  in  this  document  is  philosophically  different 
from  the  Protocol  currently  under  implementation  for  the  ARPA 
Network . 

In  this  protocol  scheme,  connections  are  non-permanent 
entities  that  are  established  each  time  a  message  is  communicated 
between  processes.  Each  message  carries  a  complete  set  of 
identification  information,  including  the  receive  and  send  socket 
pair.  A  rendezvous  scheme,  that  permits  dynamic  reconnection  to 
occur,  is  an  intrinsic  part  of  the  basic  communication  procedure. 
Although  this  scheme  is  not  suitable  for  incorporation  with  the 
current  protocol  implementation  for  the  ARPA  Network,  it  is  a 
document  worthy  of  study  for  possible  application  to  future 
protocol  efforts. 
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Che  basic  function  of  the  IMP  computer  network  is  to  allow  large  exist¬ 
ing  time-shared  (Host)  computers  with  different  system  configurations  to 
communicate  with  each  other.  Each  IMP  (Interface  Message  Processor) 
computer  accepts  messages  for  its  Host  from  other  Host  computers  and 
transmits  messages  from  its  Host  to  other  Hosts.  Since  there  will  not 
always  be  a  direct  link  between  two  Hosts  that  wish  to  communicate, 
individual  IMPs  will,  from  time  to  time,  perform  the  function  of  trans¬ 
ferring  a  message  between  Hosts  that  are  not  directly  connected.  This 
then  leads  to  the  two  basic  IMP  configurations  —  interfacing  between 
Host  computers  and  acting  as  a  message  switcher  in  the  IMP  network. 

The  message  switching  is  performed  as  a  store  and  forward  operation. 

Each  IMP  adapts  its  message  routine  to  the  condition  of  those  portions 
of  the  IMP  network  to  which  it  is  connected.''-,  IMPs  regularly  measure 
network  performance  and  report  in  special  messages  to  the  network 
measurement  center.  Provision  of  a  tracirfg  capability  permits  the  net 
operation  to  be  studied  comprehensively .  An  automatic  trouble  reporting 
capability  detects  a  variety  of  network  difficulties  and  reports  them 
to  an  interested  Host}-*.  An  IMP  can  throw  away  packets  that  it  has  receiv¬ 
ed  but  not  yet  acknowledged,  transmitting  packets  to  other  IMPs  at  its 
own  discretion.  Self-contained  network  operation  is  designed  to  protect 
and  deliver  messages  from  the  source  Host  to  the  destination  IMP. 
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